Skip to content

fix: Bug P1 omniroute provider compatibility issues - #240

Closed
JamesDAdams wants to merge 1 commit into
co-l:mainfrom
JamesDAdams:fix/omniroute
Closed

fix: Bug P1 omniroute provider compatibility issues#240
JamesDAdams wants to merge 1 commit into
co-l:mainfrom
JamesDAdams:fix/omniroute

Conversation

@JamesDAdams

Copy link
Copy Markdown
Contributor

Summary

Fix compatibility issues with strict OpenAI-compatible providers (Omniroute, Gemini via proxy):

  1. top_p sent as null: When no topP is configured, undefined was serialized to null in the JSON body. Omniroute rejects this with "top_p: must be a number". Fixed by conditionally omitting the field.
  2. project-tasks tool schema: The attachments parameter was declared as type: "array" without an items field. Gemini (via Antigravity/Omniroute) rejects this with INVALID_ARGUMENT: missing field. Fixed by adding items: {}.
  3. LLM stream error log: logger.error('LLM stream error', { error }) was serializing the Error object to {code, name} only, hiding the actual message. Fixed by using String(error).

AI-Enhanced Development

Tell what models helped shape this PR:

  • AI Models: gh/claude-sonnet-4.6

No AI used? Enter 'none'

Cache Impact

Does this PR affect anything cached — system prompts, tool definitions, skills, or other context?

  • Yesproject-tasks tool definition changed (added items: {} to attachments array schema). This affects tool definition caching for any provider that caches prompt/tool context.

- omit top_p from request body when undefined (strict providers reject null)
- add items field to project-tasks tool attachments array schema (Gemini rejects arrays without items)
- improve LLM stream error log to include message via String(error)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant